\section{Introduction}

\subsection{Scope}

The \textbf{Lemona} project aims at providing a secure, complete and efficient
mean of monitoring a computer system. Related papers and projects
referenced in this document are based mostly on Linux- and UNIX-based
systems, although most of the concepts are applicable to other
operating systems. Thus, references made to the "\emph{kernel}" or "system"
should be interpreted as being Linux when not otherwise specified.


\subsection{Background}

\subsubsection{Cyber-Criminality}

Over the last decades, companies and individuals have undergone a
shift from legacy information processing systems to computerized
information systems. This trend largely impacts the usage and access
policies of valuable assets. Unfortunately, the modern enterprise and
private models of information processing are as exposed as their
ancestors, and we recognize a matching raise of cyber-robbery and
malevolent misuse.


\subsubsection{Computer Forensics}

Forensic science (commonly referred to as simply "forensics"), aims to
answer questions asked by the legal system to establish the liability
of individuals in relation to criminal acts. It naturally encompasses
what we call computer forensics, which is a specific branch pertaining
to legal evidence being looked for and examined in digital systems.

Computer forensic science mostly aims at collecting digital evidence
to prove the ownership and retransmission of illegal information by an
individual, or to recreate and prove the logical course of action
followed by an attacker while providing proof of the attacker's
wrongdoing. In doing so, a forensics analysis determines the course of
actions which led to the state of a digital artifact. Such an artifact
can be either a storage media or a static or mobile piece of
electronic information (for instance an electronic document or a
sequence of network packets).

Examples of typical case studies and illegal activities are diverse
\cite{knight:VULNERABILITIES}:

\begin{itemize}
  \item network intrusions;
  \item corruption of private or corporate data;
  \item stealing of private or corporate data;
  \item the publication and storage of illegal content.
\end{itemize}

The role of the forensics expert, in a legal context, is to provide \cite{balon:CIF}:

\begin{itemize}
  \item the technical information bound to the criminal act;
  \item the skills and technological background to understand its surroundings;
  \item evidence of the absence or presence of the crime.
\end{itemize}

Considering this setting, it means computer forensics analysis has to
be led following a very strict, professional and documented
protocol. In effect, every action of the forensics team has to be
recorded and should prove the validity of its method and its results.


\subsubsection{Evidence}

When a team of computer forensics experts conducts the analysis of a
digital crime scene, it faces several challenges, which constitute a
critical path to the acceptance of any potential evidence produced as
an outcome \cite{rogers:FORENSICS}:

\begin{itemize}
  \item Admissible
  \begin{itemize}
    \item Must be able to be used in court or elsewhere;
  \end{itemize}
  \item Authentic
  \begin{itemize}
    \item Evidence relates to incident in relevant way;
  \end{itemize}
  \item Complete (no tunnel vision)
  \begin{itemize}
    \item Exculpatory evidence for alternative suspects;
  \end{itemize}
  \item Reliable
  \begin{itemize}
    \item No question about authenticity \& veracity;
  \end{itemize}
  \item Believable
  \begin{itemize}
    \item Clear, easy to understand, and believable by a jury.
  \end{itemize}
\end{itemize}

While computer forensics is not an entirely new field per se, there
are still gray areas in its legal definition and
application. Therefore, it is important to pay crucial attention to
the details of the forensics analysis setting and its execution.

In addition, a company who wants to protect its digital assets might
want to reuse various components of an Information Security Management
System or a similar framework, destined to prevent the destruction
and/or stealth of its corporate information, and to facilitate its
recovery, should the worst happen.

Such concerns, though not addressed in this document, are in close
relationship with its content, as some of the elements described in
existing specifications of such frameworks are part of the general
concepts of computer forensics we describe, or applied by the
solutions we review.

In the context of a company in the position of building a legally
receivable case, the questions we aim to ask and answer in this paper
are the following:

\begin{itemize}
  \item What information is available on a common system (default installation)?
  \item What information should be collected?
  \item How can this information be collected?
  \item How can this information be stored?
  \item How can this information be transferred?
  \item What impact will be induced on system performance by the gathering of information?
\end{itemize}

This brings us to consider the various elements of a forensics analysis system:

\begin{itemize}
  \item The data source/host system,
  \item The data samples themselves,
  \item The data storage system.
\end{itemize}

These questions have several aspects pertaining to the collected
information (the "data"), regarding its court wise validity and value:

\begin{itemize}
  \item Exhaustiveness,
  \item Integrity,
  \item Confidentiality,
  \item Reliability.
\end{itemize}

These values match the CIA elements (see Figure \ref{fig:fig1}).

\begin{figure*}
  \begin{centering}
  \centering
  \includegraphics[scale=0.40]{images/security/lemona-security-concepts-cia.png}
  \caption{The CIA Elements of Security}
  \label{fig:fig1}
  \end{centering}
\end{figure*}

\subsubsection{Threats and Countermeasures}

\paragraph{Intrusions}

Before going further, let us quickly explain what type of intrusion
and attacks a computer system can be exposed to and what can we do,
from a forensics point-of-view, to detect these attacks.

William Stallings defined three distinct types of Computer Intrusion
\cite{stallings:NETCRYPTO}:

\subparagraph{Masquerader}

An individual who is not authorized to use the computer and who
penetrates a system's access controls to exploit a legitimate user
account.

\subparagraph{Misfeasor}

A legitimate user who accesses data, programs, or resources for
which such access is not authorized, or who is authorized for such
access but misuses his or her privileges.

\subparagraph{Clandestine User}

An individual who seizes supervisory control of the system and uses
this control to evade auditing and access controls or to suppress
audit collection.

\paragraph{Vulnerabilities}

In 2000, Eric Knight gave an exhausting list of Computer
Vulnerabilities \cite{knight:VULNERABILITIES}, although time has
passed they are still the same nowadays:

\subparagraph{Logic Errors}

Mistakes in the design of the software that allows a security breach.

\subparagraph{Social Engineering}

\begin{itemize}
  \item "Art of personal manipulation"
  \item "Human Element of Security" \cite{mitnick:DECEPTION}
\end{itemize}

\subparagraph{Computer Weakness}

Very similar to vulnerabilities, the difference being that weaknesses
might never have a resolution (e.g. encryption key size).

\subparagraph{Policy Oversights}

Does not necessarily involve people, can be simple "Act of God" such
as fire or hardware failures.

\subparagraph{Faults}

Commonly known as bugs, or human errors.

\begin{figure*}
  \begin{centering}
    \centering
    \includegraphics[scale=0.40]{images/security/lemona-security-concepts-threats.png}
    \caption{Common Threats}
    \label{fig:fig2}
  \end{centering}
\end{figure*}

\paragraph{Aftermath}

When one of the above vulnerabilities is successfully applied to
perform an intrusion, computer forensics is used to
\cite{tan:READINESS, balon:CIF, rekhis:TADISI}:

\begin{itemize}
  \item assess that an intrusion has happened;
  \item determine what has been affected;
  \item examine the circumstances and causes.
\end{itemize}

In order to do so, evidences can be collected from various sources
\cite{tan:READINESS, balon:CIF}:

\begin{itemize}
  \item Memory Units:
  \begin{itemize}
    \item Hard Drives,
    \item Random Access Memory,
    \item External Memory Units,
  \end{itemize}
  \item System Logs,
  \item Network Traffic,
  \item IDS (both NIDS, HIDS),
  \item Physical Security.
\end{itemize}

However, on a default system only System Logs level would be
available. Unfortunately, they can be easily modified by the attacker
and are not configured to log as many data as possible by default and
these are often not kept long enough or in a secure location. On the
other hand, \emph{IDS} and Physical Security when installed and
correctly configured can cut down forensics investigation time in half
\cite{tan:READINESS}.


\subsection{Research Problem}

A post-mortem forensics system shall allow investigators to examine
targeted systems (or a legally valid reproduction) after their
decommission or destruction. Therefore, whether the system and its
data can still be accessed or not, and whether the attack covered or
not the tracks of his intrusion, does not have any value.

To obtain these capabilities, a system must be permanently
scrutinized, with the lowest level of monitoring possible, so that
each and every one of a user's activities is exhaustively logged. Such
a level of granularity allows the forensics team to reproduce step by
step specific time periods of the life of the now defunct system, and
to determine how it was eventually taken down. If such a solution
looks perfect from a theoretical standpoint, there are nonetheless
some problems to take into consideration:

\begin{itemize}
  \item negative performance impact on the target operating system;
  \item high network bandwidth consumption;
  \item high storage memory requirements;
  \item privacy concerns;
  \item broad-to-fine granularity adjustments;
  \item practical usability of the logs and traces.
\end{itemize}

Therefore, a post-mortem forensics analysis shall be designed with
performance and security concerns in mind. It ought to provide an
acceptable mix of fine-grained monitoring and flexibility to produce a
viable system, both from the users' point of view (in terms of speed
and responsiveness) and from the forensics analysts' point of view (in
terms of legal acceptance and recognition of the collected data as
potential evidence).

Those are the reasons for the creation of \textbf{Lemona}, which is intended to
draft an architecture relying on open communication, encryption and
logging standards. Following these architecture specifications, \textbf{Lemona}
designs and implements a decentralized post-mortem forensics analysis
system. This platform should be capable of providing fine-grained
logging capabilities to all parts of a system and reporting it to
secure storage points for further examination, while maintaining the
system's usability, building upon the empirical research provided by
similar projects.

\begin{figure*}
  \begin{centering}
    \centering
    \includegraphics[scale=0.60]{images/architecture/lemona-architecture-2.png}
    \caption{Lemona's Standard Use Case}
    \label{fig:fig3}
  \end{centering}
\end{figure*}


\subsection{Outline}

Our goal in the first part of this article is to present the current
state of the forensics software market regarding post-mortem analysis
tools. We will briefly review in the "Related Work" section the latest
literature and project research that we have been basing our research
on to confirm or infirm our results and design decisions.

We will then expose this design by detailing in the "Lemona" section
our software solution and its architecture, as well as the current
state of its implementation. We will then expose and explain the
results we have obtained so far.

Finally, we would like to discuss the possible improvements that could
be brought to \textbf{Lemona} and other alternatives directions we are in the
process of experimenting with.
